fix(error-tracking): stop exception card header label overlapping the tabs - #88176

Problem

Anyone opening an exception in a narrow pane — a split view, or a phone — saw the exception card header render ExStackpTrace: the "Exception" label painted on top of the tab bar instead of getting out of its way.

Three things combine in that one 40px row:

• the label cell carries min-w-0, which lets its grid track collapse below the label's width, but nothing clipped the overflow — so the text spilled over its neighbour rather than disappearing
• the 1fr auto 1fr template reserves two equal gutters to centre the tab bar, so the header needs 2 x label + tabs of width before anything fits, even though only one gutter has content — which reaches the collapsing regime early
• the tab bar is w-fit + whitespace-nowrap in an auto track, so under ~390px it overflows the header with nothing catching it

Changes

The header now degrades on a priority order — the action never goes, the tab bar next, the label first — keyed to the card's own width through a container query rather than the viewport, because the card lives in a resizable split pane.

overflow-hidden on the label cell is the actual overlap fix; the rest is what keeps the clip from being the first thing a person notices. The tab bar also picks up justify-start, overriding the list's own justify-center — a centred flex row that overflows spills off both edges, which would leave the first tab out of reach of the scroller.

Screenshots

Every shot is the new ExceptionCardHeaderWidths story, one card per width, rendered in Storybook.

Before — the overlap reproduces at 300px (ExStackpTrace) and 420px (ExceptStack Trace), and is absent from 560px up, which is why it only shows in a narrow pane:

After — the label gives way to the logomark below 576px and the tab bar takes the slack, scrolling at 300px:

After, with the right-hand cell occupied (ExceptionCardHeaderWidthsWithAction) — the tightest the tab bar ever gets, and View logs stays whole at every width:

How did you test this code?

ExceptionCardHeaderWidths and ExceptionCardHeaderWidthsWithAction pin each branch of the container query at 300 / 420 / 560 / 576 / 900px, the second with the right-hand action occupied so the tab bar has the least room it ever gets. Both are untagged, so visual review snapshots them. The regression they catch is the overlap itself, which no jsdom test can see — it is purely a layout outcome.

Verified by rendering those same stories against the pre-fix component: the overlap reproduces at 300px and 420px, and is gone after.

Automated checks run locally, all clean: oxfmt --check, oxlint, tsgo --noEmit. No manual testing in the running app.

Expected visual review diff

exception-card-with-footer changes on purpose. It rendered at an accidental width — w-full resolves against a shrink-to-fit storybook wrapper, so the card sized to its own content — and it now has a definite w-[1000px] like the other card stories.

Worth knowing for anyone reusing the container-query pattern: container-type: inline-size makes an element's width independent of its contents, so it contributes nothing to a shrink-to-fit ancestor. Putting it on the whole card collapsed that story to 32px. The container wraps the header alone for that reason.

Automatic notifications

• Publish to changelog?

Docs update

None — no user-facing behaviour beyond the layout itself.

Agent context

Autonomy: Human-driven (agent-assisted)

Authored with Claude Code (Opus 5). Skills invoked: /pr-closeout and /autoreview, the latter running Codex against the branch diff — it returned clean with no actionable findings.

Two decisions changed across the session, both caught by screenshotting the stories rather than by reading the CSS. The breakpoint started at @lg (512px), where the label reappears but immediately truncates to Exce..., since symmetric gutters leave only ~78px a side at that width; it moved to @xl (576px), where the full label fits. The centred-overflow clipping in the tab bar surfaced the same way.